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Packet radio presents an opportunity to 


improve speed and accuracy of message 
handling. Speed is often limited by the 
typing speed of the operators. The 


accuracy is assured during transmission, 
but is only useful if the message is 
correctly entered into the message 
handling system. The normal limits to 
message handling include a lack of fully 
qualified operators, and inability to 
use untrained people during special 
Situations such as disaster events. A 
method I have used to improve both of 
these is keystroke reduction. 


Fill in the blank programs are useful to 
assist newcomers in preparing traffic. 
These help if they keep inaccurate 
messages from entering the system, and 
if they allow professional typists to do 
high speed preparation of traffic off 
line. This traffic would be handled by 
a smaller number of amateurs operating 
the radios. This method has been used 
without keystroke reduction. With it, a 
smaller number of off line operators is 
needed to keep the traffic circuit busy. 
The radio operators should only spend 
about ten seconds per message sending 
and confirming receipt of "prepared 
messages." The normal pace of message 
handling by a good CW operator is one 
per minute. We should be designing and 
testing for a six fold increase in 
speed. 


The most basic method_of. automating this 
process is to save fields that do not 


change over several messages. FOr -a 
large operation this includes, 
precedence, handling instructions, 
station and place of origin, and date. 
In some cases, much of the text may be 
the same also. These can either be 
filled in and transmitted clear test, or 
"booked" and sent once at the start of 
each book. 


Automatic sequence numbering is normally 
tried next. This works fine if only one 
computer is used for text entry. If two 
or more are used for off line for text 
entry, then a method to prevent 
duplication of message numbers must be 
included. I used a limiter, which allow 
each operator to start at a specific 
message umber, assigned by a single 
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coordinator, and only enter ten 
messages. In Lis Way, several 


operators will not use the same number 
Over. I expect ten messages to take 
five minutes for typing. 


The best timesaver of all is automatic 
word counting. I implemented this in 


both basic and. -2:n 8080 assembly 
language. It counted letter groups 
separated by spaces. This seems to 


match the rules used by the ARRL in 
counting words. One special case had to 
be handled, the last word at the end of 
a line. The assembly language version 
had to take special care to treat non 
printing characters properly, Delete 
characters did not break words, and 
neither did backspaces. Carriage 
returns, however, were similar to spaces 
and I included both as "word 
delimiters." The basic version counted 
about 20 characters a second, using an 
interpreted version of BASIC. The 
assembly language version has been to 
fast to bother with timing. .A further 
benefit of this module is that is the 
text can be located in the received 
message, it can be counted and compared 
with the "check" field, further saving 
time for the receiving operator. 


None of this is any value unless the 
implementation allows a typist to back 
up and correct text in error. One 
version, from N5EZM, allowed the 
preamble to be reviewed and changed when 
first entered. No further correction 
was provided. after the last field was 
complete. If anything was wrong, the 
message had to be fixed with a text 
editor. This slows down the whole 
process, and discourages the correction 
of small errors. Error correction must 
be included in the message creation 
package. 


Tests were not useful because only one 
computer was used for bothtext entry 
and on air operation. Also, we have not 
had an event present enough traffic to 
reach the planned rate of message 
handling, over sixty messages per hour. 


The PACGRAM application allows all parts 
of an ARRL radiogram to be identified by 
a computer by delimiting each field. 


This allows routing of messages by 
city/state, and automatic word counting 
at receive points to check for flow 
control problems. While PACGRAM creates 
long frames, operation with PACLEN set 
to smaller values can be used to improve 
Operation on marginal paths. The 
PACGRAM definition is included as an 
attachment. 


Automatic message assistance 
applications have potential. They will 
be most useful where large volumes of 
similar traffic are generated, or when 
fast liaison with the NTS is required. 
Official traffic for disaster relief 
agencies is not likely to benefit as 
much from these developments. 


>>>>>>> >>> ~»> Pacgram Protocol Definition< <<< <<< <<< 
(Versions 1.5.0 and later) 


By: Jay Nugent, WB8TKL 
3081 Braeburn Circle 
Ann Arbor, Michigan 48104 
Dated: 860128 


PACGRAM is an application software package that runs on the host computer 
connected to a TNC. The PACGRAM software is responsible for prompting the 
operator for the proper Radiogram information one field at a time and forms a 
PACGRAM message from this. The message can then be sent to the TNC for 
transmission into the network. 


On the receiving end, PACGRAM decodes the data stream from the TNC for the 
starting characters of a PACGRAM. When it finds these characters it receives 
the rest of the message and can later decode it back into the Radiogram format 
for display on the console, or as printed on the printer. Received PACGRAMS are 
stored in buffer space and/or disk files and maybe later retransmitted for 
forwarded to other stations in the network. 


Special characters are used within the PACGRAM to signal the start of the 
PACGRAM message, the end of the PACGRAM message, and to separate the fields of 
information within the PACGRAM message. 


These control characters and the protocol are described in the following 
definition. 


-~> PACGRAM CONTROL CHARACTER and PROTOCOL DEFINITION 


The control characters, and character sequences, used in PACGRAM were based 
on the unlikelihood that they would ever appear in part of a normal Radiogram. 
Consideration of the CW traffic nets that will handle message traffic generated 
with PACGRAM was also taken into account since many characters cannot be sent 
using CW. 


For those stations not possessing PACGRAM software, these control characters 
were selected so that a PACGRAM can be read directly from a terminal and written 
back into the standard Radiogram form very easily by hand. A Formsmode has been 
added to the protocol to allow the sending of a directly printable PACGRAM. 
This enables any station to receive a PACGRAM already formatted to be printed on 
hardcopy. This form of PACGRAM uses its own starting sequence that can be 
easily detected by a small computer running BASIC. Once the start sequence is 
detected, it can then route all output to the printer. The standard end of 
PACGRAM character is used to indicate the end of the print so that the output 
can then be routed back to the console. 


~-> The START of a PACGRAM shall be a pound sign '#' followed by asterisk '*'. 

The purpose of this character sequence is to signal the start of a PACGRAM 
and differentiate it from any other data sent by the TNC to the host computer. 
Such as other communications data or commands and responses from the TNC, 


The start of the PACGRAM sequence has been altered since the first release 
of this protocol in an effort to avoid false starts caused by WORLI like PBBS's 
that use the # character in their data. 
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--> The DELINEATION character shall be an asterisk '*', 


This character is present in the PACGRAM to delineate the standard Radiogram 
fields from one another. The absence of data in any one of the fields will 
cause two consecutive asterisks to appear within the PACGRAM. No filler 
characters are placed between the asterisks of an empty field. 


--> The FIELD ORDER of a PACGRM is as follows. 


NUMBER / PRECEDENCE / HANDLING INSTRUCTIONS / STATION OF ORIGIN 
CHECK / PLACE OF ORIGIN / TIME FILED / DATE FILED 


NAME TO / NUMBER & STREET / CITY / STATE / ZIP / PHONE NUMBER 
TEXT OF THE MESSAGE 
SIGNATURE / TITLE OF SIGNEE 


Note: The CITY and STATE fields have been separated into two individual fields 
in this version of the protocol. This allows for automated routing based on the 
destination City and State. 


--> FIELD LENGTHS and TYPES within the PACGRAM. 


The Number field will be limited to 8 characters maximum. 

The Check field will be limited to 2 characters maximum. 
(This may be expanded to handle ARL type checks) 

The Text field is limited to a maximum of 1024 characters. 

All other fields are limited to 60 characters. 


Field types may be either alphabetic or numeric but characters that cannot be 
sent using CW will not be allowed. 


--> The END or a PACGRAM shall be the ampre sign 'gé', 
The purpose of this character is to signal the end of the PACGRAM. 


--> The START of a FORMSMODE PACGRAM shall be '#PAC&' followed by a carriage 
return. 


The purpose of this starting sequence (including the carriage return) is to 
signal the start of a PACGRAM in the FORMSMODE. A small computer running a 
BASIC program can trap this starting sequence and then direct all its output to 
a printer. 


--> The END of a FORMSMODE PACGRAM shall be an ampre sign '&' followed by a 
carriage return. 


The purpose of the end of FORMSMODE sequence is to signal the end of a 
FORMSMODE PACGRAM. A small computer running a BASIC program can trap this 
sequence and then direct its output back to the console. 
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As a Radiogram has well defined fields in a specific order, so does the 
PACGRAM. The order in which the fields occur in the Radiogram is the exact 
order that they will appear in the PACGRAM. For example, here is a sample 
Radiogram followed by its equivalent data stream in PACGRAM form. 


NUMBER: 126 ROUTINE WB8TKL CHECK: 5 ANN ARBOR MI 14302 MAY 21 
TO: MIKE NUGENT 
123 HOLLYWOOD AVE 
HOLLYWOOD, CAL 54321 
(818) 555-1234 
TEXT: HOW IS THE WEATHER X 
SIGNED: JAY 


and the equivalent in PACGRAM form would be: 


#*126 *R**WBSTKL*5*ANN ARBOR MI*14302*0521*MIKE NUGENT*123 HOLLYWOOD 
AVE* HOLLYWOOD * CAL*54321* (818) 555-1234*HOW IS THE WEATHER X*JAY**& 
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As you can see, the length is well within 256 bytes, the maximum AX.25 
packet length. Even with the Paclen set to 256, a single packet could contain a 
fairly large text field. You can see the benefits of using PACGRAMS over the 
voice or CW methods of sending traffic. This packet can be sent in just a 
fraction over one second at 12 bps, an enormous improvement over existing 
amateur traffic systems. 


Also notice that in my example, since I left the fields for Handling 
Instructions and Title blank, that PACGRAM simply put no data between the two 
asterisks. This 18 necessary to maintain the field count for decoding of the 
PACGRAM at the receiving end and also wastes as little of the transmission 
bandwidth as possible. 


Happy Packeting ~WB8TKL 
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